IBIS Macromodel Task Group

Meeting date: 19 October 2021

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                            * Majid Ahadi
                              Ming Yan
                            * Radek Biernacki
                            * Rui Yang
                              Todd Bermensolo
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Majid Ahadi introduced himself to ATM.  He had recently attended his first
  Open Forum meeting as well.  He received his Ph.D. from Georgia tech in May of
  2021.  He joined Keysight and is working on developing their AMI model building
  tools in ADS.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 12th
meeting.  Randy moved to approve the minutes.  Bob seconded the motion.
There were no objections.

-------------
New Discussion:

GDDR6X:
Walter and Randy said they had no new updates.  Walter summarized the current
status.  He said we had proposed solution from 2 different EDA companies that
think they know how Tx GetWave functions could deal with the issues GDDR6X
presents (see previous weeks' minutes for discussion of the issues).  He said
we expect to be able to evaluate various solutions in the future as more data
from device manufacturers is made available for validation.

Supporting PI modeling/simulation in IBIS:
Randy reported that he is performing simulations on buffers to gather data that
might be helpful to Chulsoon Hwang as he drafts a PSIJ BIRD.  He said he is
sanitizing the data and expects to have something to share in the coming weeks
and send to Chulsoon.

Walter commented that there are two broad categories of PI modeling.  There is
the total power the chip uses, and there is SSO.  Both are related to power, but
SSO is related to local power and crosstalk.  When some people do PI, they are
looking at the total power requirements of the chip.  Walter said nothing IBIS
has done traditionally deals with total power consumption of the chip.  He said
perhaps only 20 to 30% of that total is related to I/O device power.  The total
chip requirements are much larger than SSO related power draw, and the frequency
dependency of the power is mostly related to core power.  If we are considering
SSO, then the IBIS power-aware models make sense.  However, for full chip PI,
IBIS is missing much larger parts.

Randy said Chulsoon's PSIJ proposal is relative to the SSO and is more of an
effect of PI on SI.  He said Zhiping is working on other proposals to look at
more global PI considerations.  Walter said power spectral density is used to
capture power load variations from the whole chip.  We may want to propose
keywords to handle the power spectral density, and IBIS needs to be careful to
make sure we distinguish between the two PI categories.

BIRD209 (originally BIRD204):
Arpad asked about the BIRD's new Rx_Use_Clock_Input parameter.  In the Usage
Rules, he wondered whether we gave enough specifics about what portion of the
.dll function(s) signatures are used.  He asked if the tool should just copy the
waveform output of the DQS GetWave to the clock_times input of the DQ GetWave
(if the value of Rx_Use_Clock_Input for the DQ GetWave is "Wave").  Walter
agreed this was the intent.  He noted that the tool could conceivably pass the
pointer around instead, but this could be dangerous.

Arpad asked if we thought that more clarifying text was needed.  Ambrish said he
thought there was no need to change.  Curtis agreed with Ambrish.  Fangyi said
this confusion might be more likely since we are overloading the clock_times
vector, which was previously only an output from the model.  Fangyi suggested
you could think of this use of clock_times like a C union type.  Walter said
that the EDA vendors in attendance seemed to think the existing description is
sufficient.  He said the question will be whether other people writing model
wrappers and tools find it clear.  The group decided no action was needed at
this time.

GitHub Model Library repository proposal:
Radek noted that Chulsoon and Zhiping had presented a demo of a potential GitHub
site for storing IBIS model libraries.  He asked whether ATM should invite them
to present here.  Arpad said he wasn't sure it was in our purview.  Radek said
the goal is modernizing distribution of libraries, but he wasn't entirely sure
it was necessary.  Randy said the Open Forum presentation had shown a demo and
discussed possible access control levels (those who can download only, those who
can upload, etc.).  Arpad said he had asked if this might allow older models
that the original authors had stopped supporting to be updated, for example, if
an old AMI file had a Model Specific parameter that had since been approved as a
Reserved Parameter.  Walter said he thought models in the library were best used
as references and examples of what had been done in the past.  He said it would
be risky to modify old models and not be using the latest approved models from
your vendor.  Ambrish said it would be problematic to have someone who doesn't
own a model attempt to modify it.  Since several attendees had missed the Open
Forum meeting and were interested in seeing Chulsoon's demo, Arpad took an AR to
invite him to present the concept to ATM.

Automotive SERDES conference:
Walter said that he had recently attended an automotive SERDES conference in
Berlin.  He noted that in the automotive industry many of the existing
electronic devices are proprietary and done independently by different
manufacturers.  He said the auto industry is now making an effort to standardize
many cables, sensors, etc., and they are now going to SERDES because of band-
width requirements.  He noted that one of their biggest bandwidth issues is
being driven by the proliferation of 4K video monitors in cars.  In addition,
there are bandwidth requirements because of all the sensors for autonomous
driving.  He reported that they were discussing settling on standards for PAM2,
PAM4, PAM8, and PAM16.

Arpad asked if Walter expected that there would be SERDES developments that are
entirely new to those of us in the field.  Walter said he thought the automotive
industry would be working in the same general realm as we were when AMI modeling
started.  He said they were typically 6 to 10 Gbps in NRZ.  He said they will
certainly go to PAM4, and they say they want PAM8 and PAM16.  He said they might
be able to do it since they are only talking about 2G symbols/sec.  He noted
that they plan to use FEC on some channels.  He said another interesting point
is that many of their channels are highly asymmetric.  Most channels we've
typically considered in IBIS-AMI are symmetric in that they have the same band-
width in both directions.  In automotive applications many devices, for example,
a video camera sensor, only need high bandwidth in one direction.  He said in
some cases they're looking at up to 14m long coax cables or 10m long dual-
shielded differential cables.

Jitter Decomposition:
Walter raised a new topic.  He said we often talk about random, deterministic,
sinusoidal, etc., jitter terms.  We talk about some mathematical descriptions
that don't exist in reality.  In the real world, a scope measures the waveform,
creates an eye, and then does jitter decomposition.  It looks at the histogram
of the eye crossings at zero volts.  Sometimes it has two bumps, or one narrow
or wide bump, etc.  Typically, the scope tries to decompose that into
deterministic and unbounded jitter (Dj and Rj).  He said he suspects that every
manufacturer has their own way of doing decomposition.

Walter said standards are often vague or have differing rules on how jitter
decomposition is done.  Walter said there might be an opportunity for IBIS to
come up with terminology and algorithms for decomposition.  People could
contribute various methods for doing the decomposition, and these could be
defined and published by IBIS so companies can refer to a standard when they
implement decomposition.  He wondered if some test equipment organization had
already done this, and he said there might be an opportunity for IBIS if they
hadn't.

Arpad asked how much this would have to do with device modeling.  Radek said
vendors want to mimic the behavior of their measured devices.  They asked what
the interest would be for AMI simulation.  Walter said if someone is evaluating
a channel, they want to know if it will pass a jitter compliance test:
    channel -> simulation -> eye diagram -> compliance test.
    
Majid said that scopes are trying to decompose the jitter components from the
measured signals.  With AMI modeling, we tend to be adding jitter in to the
simulation results, i.e., composing jitter as opposed to decomposing.  Walter
agreed partially.  He said that even if you do an AMI simulation without
introducing jitter explicitly, the ISI and other effects of the channel are
already included in your results.  So, simulation could also make use of
decomposition.

Fangyi noted that mathematically, jitter can't be separated into its components.
He referred to a paper he had presented at DesignCon in 2014.  Walter agreed.
Fangyi said that because of this fact any jitter decomposition depends on
assumptions.  These are more like a definition than a mathematical description.
He said any method that speeds up the jitter decomposition process might vary
from algorithm to algorithm (because they are based on different assumptions).
That intellectual property is properly kept proprietary to the vendor.  Walter
agreed that every vendor may have a proprietary implementation.  Fangyi said
standards sometimes have their own definition of jitter.  Walter said sometimes
they don't define it well enough.  Fangyi agreed.  Arpad said we could continue
the discussion next week.

- Walter: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.

AR:  Arpad to invite Chulsoon to present his GitHub model library proposal to
     ATM.

-------------
Next meeting: 26 October 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
